**************** 




Disclosure to Promote the Right To Information 

Whereas the Parliament of India has set out to provide a practical regime of right to 
information for citizens to secure access to information under the control of public authorities, 
in order to promote transparency and accountability in the working of every public authority, 
and whereas the attached publication of the Bureau of Indian Standards is of particular interest 
to the public, particularly disadvantaged communities and those engaged in the pursuit of 
education and knowledge, the attached public safety standard is made available to promote the 
timely dissemination of this information in an accurate manner to the public. 
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BASIC REFERENCE MODEL OF OPEN 

SYTEMS INTERCONNECTION FOR 
INFORMATION PROCESSING SYSTEMS 

PART 3 NAMING AND ADDRESSING 

NATIONAL FOREWORD 

This Indian Standard which is identical with ISO 7498-3 : 1989 ^Information processing 
systems — Open systems interconnection — Basic reference model — Part 3: Naming and 
addressing', issued by the International Organization for Standardization ( ISO ) was adopted 
by the Bureau of Indian Standards on the recommendation of Computer Systems and Inter- 
connection Sectional Committee ( LTD 36 ) and approval of the Electronics and Telecommuni- 
cation Division Council. 

In the adopted standard certain terminology and conventions are however not identical to 
those used in Indian Standards. Attention is particularly drawn to the following: 

Wherever the words 'International Standard' appear referring to this standard, they 
should be read as *Indian Standard'. 

In^this Indian Standard, the following International Standards are referred to. Read in their 
respective place the following: 

International Standard Indian Standard Degree of 

Equivalence 



ISO 7498 : 1984 Information pro- 
cessing systems — Open systems 
interconnection — Basic Refer- 
ence model 

ISO 7498-4 : 1989 Information pro- 
cessing systems — Open systems 
interconnection — Basic refer- 
ence model — Part 4 : Manage- 
ment framework 

ISO 7498/ Add 1 : 1984 Information 
processing systems — Open 

systems interconnection — Basic 
Reference model — Addendum 1 : 
Connectionless-mode transmission 



IS 12373 : 1987 Basic reference 
model of open systems inter- 
connection for information 
processing systems 

IS 12373 ( Part 4) : 1992 Basic 
reference model of open systems 
interconnection for information 
processing system : Part 4 
Management framework 

Amendment No. 2 to IS 12373 : 
1987 Basic reference model of 
open systems interconnection 
for information processing 
systems 



Identical 



Identical 



Identical 



The technical committee responsible for the preparation of this standard has reviewed the 
provisions of the following ISO Standards and has decided that they are acceptable for use in 
conjunction with this standard: 

ISO 8348/ Add. 2 : 1988 • Information processing systems — Data communication — 
Network service definition — Addendum 2 : Network layer addressing 

ISO/TR 8509 : 1987 Information processing systems — Open systems interconnection — 
Service conventions 

ISO 9545 : 1989 Information processing systems — Open systems interconnection — 
Application layer structure 
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Introduction 

This part of the Basic Reference Model for Open 
Systems Interconnection (ISO 7498) extends the 
basic architectural concepts of identifiers described 
in 5.4 of ISO 7498. 

This part of ISO 7498 states the architectural 
principles which are followed in the production of 
any standard which involves the identification 
(naming) and location (addressing) of objects for 
the purpose of interconnection within the Open 
System Interconnection Environment (OSIE). 

This part of ISO 7498 has sufficient flexibility to 
accommodate advances in technology and 
expansion in user demands. This flexibility is 
also intended to allow the phased transition from 
existing implementations to OSI standards. 

NOTE - This part of ISO 7498 is expected to be subject 
to future expansion, in particular with regard to Multi- 
Peer Data Transmission (MPDT). 

The architectural principles stated within this part 
of ISO 7498 ensure that any ISO standard that in- 
volves the identification and location of objects 
within the OSIE for the purpose of 
interconnection will: 

a) avoid any restrictions on: 

1) the functionality that may be made 
available through current or future 
International Standards, 

2) the functionality of any real open 
system, 

3) the internal design of any real open 
system; 

b) preserve the principle of layer 
independence in the OSIE. That is, the 
internal functioning of one layer is not 
constrained by any other layer; 

c) preserve the principle of implementation 
independence in the OSIE, as expressed in 4.2 
of ISO 7498. That is, no real open system 
(or administrator thereof) is required to know 
anything about the implementation design of 
any other real open system (or administration 
thereoO, nor does any real open system 
impose such knowledge as a condition for 
communication using OSI standards; 

<$ allow economical support for 
interconnection within the OSIE; in particular 
individual standards produced within the 



framework specified by this part of ISO 7498 
should make it possible to provide facilities 
which give adequate levels of performance, 
reliability, and integrity and which ease the 
administration by humans with respect to 
identifying and locating objects within the 
OSIE for the purpose of interconnection. 

The description of naming and addressing for the 
OSIE given in this part of ISO 7498 is developed 
in stages. 

Clauses 1 - 4 provide basic introductory and 
reference information. 

Clause 5 introduces concepts of naming. 

Clause 6 prescribes, for the OSIE, the objects 
named, the operation of addressing, and the uses of 
addressing. 

Clause 7 prescribes, for the OSIE, the objective of 
naming and addressing and the mechanisms to be 
employed to meet that objective. 



Clause 8 prescribes the principles governing the 
nature and use of addressing information in (N)- 
services. 



Clause 9 prescribes the principles governing the 
nature and use of addressing information in (N)- 
protocols. 

Clause 10 provides a layer independent description 
of the layer directory-functions necessary to 
support the addressing structure established by 
clauses 7, 8, and 9, based on the general 
mechanisms and principles established in clauses 
5 and 6. 

Clause 1 1 prescribes the use of the directory-func- 
tions in each layer. 

Clause 12 defines the natiu^e of addressing domains 

and registration authorities. 

Clause 13 prescribes the registration procedures 
required for naming in the OSIE. 

Clause 14 prescribes the requirements for directory 
facilities in the OSIE. 

NOTE -This part of ISO 7498 provides clarifications of 
the basic architecture defined in ISO 7498 wher^this is 
necessary for a full understanding of the naming and ad- 
dressing requirements within the OSIE. 
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1 Scope 

This part of ISO 7498: 

a) defines general mechanisms for the use of 
names and addresses to identify and locate objects in 
the OSIE; and 

b) defines the use of these mechanisms within the 
layered structure of the Basic Reference Model. 

This part of ISO 7498 extends the concepts and princi- 
ples defined in ISO 7498. This part is not intended to be 
cither an implementation specification or a basis for ap- 
praising the conformance of actual implementations. 

The specific form of names and addresses is not within 
the scope of this part. 



2 Normative references 

The following standards contain provisions which, 
through reference in this text, constitute provisions of 
this part of ISO 7498. At the time of publication, the 
editions \ndicated were valid. All standards are subject to 
revision, and parlies to agreements based on this part of 
ISO 7498 are encouraged to investigate the possibility of 
applying the most recent editions of the standards listed 
below. Members of lEC and ISO maintain registers of 
currently valid Intemational- Standards. 

ISO 7498:1984, Information processing systems - Open 
systems interconnection - Basic reference model 

ISO 7498/Add. 1:1984, Information processing systems 
- Open systems interconnection - Basic Reference Model 
' Addendum 1 : Connectionless-mode transmission. 

ISO 7498-4:-^ ), Information processing systems - Open 
systems interconnection - Basic Reference Model - Part 
4: OSI management framework. 

ISO 8348/Add. 2: 1988, Information processing 
systems - Data communication - Network service 
definition - Addendum 2 .Network layer addressing. 

ISO/TR 8509:1987, Information processing systems 
Open systems interconnection - Service conventions. 



ISO 9545:-^ \ Information processing systems - Open 
systems interconnection - Application layer structure. 



3 definitions 

3.1 This part of ISO 7498 makes use of the following 

terms defined in ISO 9545: 

a) application-process-type; 

b) application-process-invocation. 

3.2 This part of ISO 7498 makes use of the following 
terms defined in ISOyTR 8509: 

a) (N)-service-request-primitive, 

b) (N)-service-indication-primitive, 

c) (N)-service-response-primitive, 

d) (N)-service-confirm-primitive. 

3.3 This part of ISO 7498 makes use of the following 
term defined in ISO 8348/Add. 2: 

a) subnetwork point of attachment 

3.4 For the purpose of this part of ISO 7498, the 
following definitions apply. 



3.4.1 (N)-address: A name unambiguous within 
the OSIE which is used to identify a set of (N)-service- 
access-points which are all located at a boundary between 
an (N)-subsystem and an (N+l)-subsystem in the same 

open system. 

NOTES 

1 Tliis definition of (N)-address is different from that in ISO 
7498. This definition is the definitive one and will be moved to 
ISO 7498 to replace the existing definition when ISO 7498 is 
revised. 

2 A name is unambiguous within a given scope when it 
identifies one and only one object within tiiat scope. 
Unambiguity of a name does not preclude the existence of 
synonyms. 

3.4.2 (N)-address-selector; (N)-selector: An 

element of addressing information that identifies a set of 
(N)-SAPs which are all in the same (N)-^ubsystem; an 
(N)-selector value is assigned by the local administration. 



^) To be published. 
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NOTE - The concept of (N)-address-selectors only applies above 
the Network Layer. 

3.4.3 (N)-associatioii: A cooperative relation- 
ship among (N)-entily-invocations. 

NOTE - This may be formed by the exchange of (N)-protocol- 
control-information. 

3.4.4 calling-(N)-address: A paran^eter which 
may appear in an (N)-service request or indication primi- 
tive and which identifies the (N)-address at the (N)-initia- 
tor. 

NOTE - In the service definition of a particular layer, such a 
parameter may be referred to either as a 'calling-(N)-address" or 
source-address". Throughout this part of ISO 74v8, however, 
only the term "calling-(N)-address** is used. 

3.4.5 ca!kd-(N)-address: A parameter which 
may appear in an (N)'Service request or indication primi- 
tive which identifies the (N)-address at the (N)-recipient. 

NOTE - In the service definition of a particular layer, such a 
parameter may be referred to either as a 'ca]led-rN)-addi-ess" or 
destination-address". Throughout this part of ISO 7498, how- 
ever, only the lenn "called-(N)-address" is used. 

3.4.6 descriptive name: A name that identifies a 
set of. one or more objects by means of a set of asser- 
tions concerning the properties oi the objects of the set. 

3.4.7 (N)-directory-function: An (N)-function 
that processes (N)-addresses, (N-l)-addresses, (N)-cntity- 
tiUes, and (N)-PAI to provide mappings among these 
categories of infonnation, 

3.4.8 (N)-ent!ty: An active element within an 
(N)-subsystem einoodying a set of capabilities defined for 
the (N)-iayer that corresponds to a specific (N)-entity- 
type (without any extra capabilities being used.) 

NOTE - This definition of (N)-entity is different from that in 
ISO 7498. This definition is the definitive one and will be 
moved to ISO 7498 to replace the existing definition when ISO 
7498 is revised. 

3.2.9 (N)-entity-invocation: a specific utiliza- 
tion of part or all capabilities of a given (N)-entity 
(without any extra capabilities being used). 

NOTE - litis definition will be moved to ISO 7498 to replace 
the existing definition when ISO 7498 is revised. 

3.4.10 (N)-entity-title: A name that is used to 
identify unambiguously an (N)-enuty. 

3.4.11 (N)-entity-type: a description of a class 
of (N)-entities in terms of a set of capabilities defined for 
the (N)-layer. 

NOTE - This definition will be moved to ISO 7498 to replace 
the existing definition when ISO 7498 is revised. 

3.4.12 generic name: A nairie of a set of objects. 



NOTC - A geT>eric-title is a specific form of generic name. 

3.4.13 (N)-initiator: An (N)-enUty-invocation 
which issues an (N-l)-seTvice request primitive. 

3.4.14 name: A linguistic construct which cor- 
responds to an object in some universe of discoiu^e. 

3.4.15 naming-authority: A registration 
authority which allocates names according to specified 
rules. Where the naming-authority allocates titles, it is 
known as a tide-authority. Where the naming-authority 
allocates addresses, it is known as an addressing-author- 
ity. 

3.4.16 naming-domain: The set of names that 
are assignable to objects of a particular type. Where the 
names are titles, the set is known as a title-domain. 
Where the names are addresses, the set is known as an 
addressing-domain. 

3.4.17 naming-subdomain: A subset of a 
naming-domain, which is disjoint from all other naming- 
subdomains of that naming-domain. 

7.4.18 primitive name: A name that identifies 
an object and which is assigned by a designated naming- 
authority. The internal structure of the name is not re- 
quired to be understood or to have significance to users of 
the name. 

3.4.19 (N)-recipient: An (N)-enuty-invocation 
which receives an (N-l)-service indication primitive. 

3.4.20 (N)-protocol-addressing-informa- 
tion; (N)-PAI: Those elements of (N)'PCI which 
contain addressing information. 

3.4.2 1 responding-(N)-address: A parameter 
which may appear in an (N)-service response or confirm 
primitive and which identifies the (N)-address at the (N)- 
recipient. 

NOTE - In the service definition of a particular layer, such a 
parameter may be referred to either as a "called-address" or 
responding address." Throughout this part of ISO 7498, 
however, only the term "responding-(N)-address" is used. 

3.4.22 (N)-ser vice-access-point-address; 
(N)-SAP-address: An (N)-ad(lress that is used to 
identify a single (N)-SAP, 

NOTES 

1 This definition of rN)-service-access-point-address is different 
from that in ISO 7498. This definition is the definitive one and 
will be moved to ISO 7498 to replace the existing definition 
when ISO 7498 is revised. 

2 (N)-address is the general term which applies to any set of 
(N)-SAPs, including sets of one and only one (N)-SAP. (N)- 
SAP address is only used where it is necessary to specify 
precisely that the address identifies one «nd only one (N)-SAP, 
Whether an (N)-address is an (N)'S AP address or not is a mailer 
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local to the (N)-subsystem and is not known to other open 
systems. Nevertheless, at some layers and because of their 
possible use in subsequent communications, calling-(N)-addresses 
and responding-(N)-addresses may be constrained to identify a 
single (N)-SAP (see 8.4.4 and 8.5.5). The decision whether or 
not to apply this constraint is made on a layer-by-layer and 
protocol-by-prolocol basis. 

3.4.23 subnetwork-address: An identifier as- 
signed to a subnetwork point of attachment by the regis- 
tration authority of the subnetwork. 

3.4.24 synonymous name; synonym: A 

name that identifies an object that is also identified by 
another distinct name. Synonymous generic names are 
distinct generic names that name the identical set. 

3.4.25 system-title: A name, unique within the 
OSIE, which is used to identify a single real open sys- 
tem. 



4 Abbreviations 

For the purposes of this part of ISO 7498, the following 
abbreviations apply: 

(N)-CEPI (N)-Connection-EndPoint-Idcntifier 

DLSAP Data-Link-ScA'ice- Access-Point 

NSAP Network-Service- Access-Point 

OSI Open Systems Interconnection 

OSIE OSI Environment 

(N)-PAI (N)-Protocol- Addressing-Information 

(N)-PCI (N)-Protocol-Control-Information 

PhSAP Physical-Service-Access-Point 

PS AP Presentation-Service- Acccss-Poini 

(N)-SAP (N)-Service-Access-Point 

SNPA SubNetwork Point of Attachment 

SSAP Session-Service- Access-Point 

TSAP Transport-Service-Access-Point 



5 Basic concepts of naming 

5.1 Names are linguistic constructs expressed in some 
language. They correspond to objects in some universe 
of discourse. The correspondence between names (in the 
language) and objects (in the universe of discourse) is the 



relation of identifying, 
which it is bound. 



A name identifies the object to 



5.2 Within the context of OSI, names identify partic- 
ular communications objects in the Open Systems In- 
terconnection Environment (OSIE). Tliere are two dis- 
tinct kinds of names, primitive and descriptive. 

5.3 Within any particular universe of discourse, a 
primitive name is a name assigned by a naming-au- 
thority to a specific object. A naming-authority is sim- 
ply a source of names. The only architectural constraints 
imposed upon naming-authorities are that all of the 
names it provides: 

a) are expressed in a prescribed language; and 

b) are unambiguous (identify just one object). 

5.4 A descriptive name consists of a set of assertions 
which are expressed in a formally defined language. The 
definition of the formal language determines those lin- 
guistic constructs which are well-formed descriptive 
names. A descriptive name may be incomplete, in that 
many objects satisfy all the assertions, or it may be 
complete, in that it serves to identify a single object. A 
complete descriptive name is equivalent to a primitive 
name in that it unambiguously identifies an object. 
Primitive names may be components of a descriptive 
name. 

5.5 Although a primitive name is unambiguous, there 
may be more than one name that unambiguously identi- 
fies the s;iine object. 

5.6 A generic name is a primitive name or a descriptive 
name that identifies a set comprising more than one ob- 
ject with the intent that, when a generic name is used to 
denote an object, the result is that exactly one member of 
the set of objects will be selected. A generic name may 
be used to identify a set of objects of a particular type, 
which need not be located in the same open system. 

5.7 A title is assigned to an object where the purpose 
of the name is to discriminate among different objects 
and to permit retrieval of information associated with an 
object from a Directory Facility. A title is assigned to 
an object type where the purpose of the name is to dis- 
criminate among diifercnt object types and to permit re- 
trieval of information associated with an object type 
from a Directory Facility. The name may identify a 
system, application-process, application-process-type, 
(N)-entity, or (N)-entity-type. 

NOTE - These objects and types are defined in either ISO 7498 
or ISO 9545. 

5.8 ^ An identifier is assigned to an object where the 
purpose of the name is only to discriminate among oc- 
curences of this object. The name may identify an (N)- 
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association, an application-process-invocation, or an (N)- 
entity-invocation. 

NOTE - These objects are defined in either ISO 7498 or ISO 
9545. 



6 OSI naming and addressing con- 
cepts and the correct use of addresses 

6.1 The naming of real open systems 

6.1.1 A system-title is a layer independent primitive 
name, i.e., the same identifier is used within various 
layers to identify the sam.e real open system. A. single 
real open system is named by one and only one system- 
title. 

6.1.2 A system-title is used to identify a real open 
system as a whole. It may also be used: 

a) in conjunction with other qualifiers to iden- 
tify specific OSI resources in the relevant parts of 
the management information base within the real 
open system; or 

b) as an attribute of a Directory Facility entry 
pertaining to an OSI resoiu*ce associated with a 
single real open system. 



dress is an (N)-address which identifies a set containing 
exacUy one (N)'SAP. 

6.2.2.2 While (N)-entities are the objects being ad- 
dressed, the result of communication to an address is 
communication with an (N)-entity-invocation. 

6.2.2.3 An (N+l)-entity is located by its binding to 
one or more (N)-SAPs. An (N)-SAP is identified by one 
or more (N)-addresses. 

NOTE - A physical-address is used to access a data-link-entity; 

a data-link-adorcss is used to access a network-entity; 

a network-address is used to access a transport-entity; 

a transport-address is used to access a session-entity; 

a session-address is used to access a presentation-entity; and 

a presentation-address is used to access an application-entity. 



6.2.3 



(N)=se!ectors 



An (N)-selector is that part of the addressing information 
which is specific to the (N)-subsystem. (N)-selectors 
are used to identify (N)-SAPs or sets of (N)-SAPs within 
an end open system, once this end open system is 
unambiguously identified. Since the end open system 
is implicitiy known at the Network Layer, (N)-selectors 
are used above the Network Layer, along with local in- 
formation, to address the desired (N-i-l)-entity within the 
open system. (N)-selector values are exchanged between 
open systems as part of the (N)-PAI. 



6.2 The naming and addressing of elements 
of an (N)-layer 



6.2,1 



Introduction 



6.2.1.1 Since an (N)-entity-type describes a class of 
(N)-entitics, it needs to be named, but not located. 
Since (N)-entities and (N)-entity-invocations are active 
elements within an (N)-layer, they need to be unambigu- 
ously identified and located. 

6.2.1.2 Within an open system, (N+i)-entities and 

(N)-cnuties axe bound together at (N)-service-access- 
points [(N)-SAPs]. (N)-enuties provide services to 
(N+l)-entitics via the exchange of service primitives at 

(N)-SAPs. 

6.2.1.3 An (N)-entity is identified unambiguously by 
an (?s)-entity-titie. An (N^-entity-type is identified by 
an (N)-entity-typc-title. An (N)-entity-invocation is 
identified by an (N)-enuty-invocation-identifier which is 
unambiguous within die scope of an (N)-entity. 

6.2.2 (N).addresses 

6.2.2.1 An (N)-address identifies a set of (N)-SAPs 
which are all located at the boundary between an (N)- 
sutBystem and an (N+l)-subsyrstcm. An (N)-SAP-ad- 



6,3 The correct use of (N)-auuresses 

6.3.1 (N)-addresses have a limited scope. They are 
used to distinguish among sets of (N)-SAPs, and only 
(N)-SAPs. Addressing rules are not used to make the 
structure of a real open system visible to the OSI 
environment 

6.3.2 (N)-addresses are used to identify sets of (N)- 
SAJ*s in order to locate (N+l)-entities. A„n (N+1)- 
subsystem is partitioned into (N-hl)-entities: 

a) to support different (N+1) -protocols or sets 
of (N+ 1 )-protocols; 

b) to accommodate security and/or management 
requirem.€nts; and 

c) in the case of the application-subsystem, to 
distinguish between different ^:^hcation -processes 
and different application-entities of the same ap- 
plication-process. 



6.3.3 (N)-addresses are not used: 

a) to distinguish among aspects of protocols 
that are subject to negotiation (classes, subsets. 
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quality of service, protocol versions) or parameter 

values; 

b) to derive routing information above the Net- 
work Layer; or 



c) 



to distinguish among hardware components. 



NOTE - In some configurations, the use of an (N)-address 
as defined in 6.3.2 can lead to an (N+l)-entity being 
wholly contained within a single hardware component. 
Nevertheless, within the OSIE, the (N)-address identifies 
the (N+l)-entity; it does not identify the hardware 
component. 



7 OSI addressing model 

7.1 Associations between peer (N)-entities 

7.1.1 An (N)-association is a cooperative relationship 
between two (N)-entity-invocations. Cooperation be- 
tween (N)-entity-invocations requires the establishment 
and maintenance of related state information in each (Id- 
entity-invocation. This state information supports an 
(N)-association between the (N)-entity-invocations. 

7.1.2 An (N)-entity invocation may support one or 
more independent (N)-associations at any one time. The 
communications behavior of the (N)-entity-invocation 
with respect to a specific (N)-association is defined by 
the (N)-entity and by the state information which is 
maintained by the (N)-entity-invocation and is specific to 
that (N)-association. 

7.1.3 An (N)-association-idcntifier is associated with 
each (N)-association. This identifier is unique within the 
scope of a pair of cooperating (N)-entity-invocalions. It 
serves to identify the related' state infonnation associated 
with each (N)-cntity-invocation. The identifier has two 
components, one being determined by each (N)-entity- 
m vocation. 

NOTE - Certain (N)-pTotocols may not need explicit (N)- 
association-identifiers. 

7.1.4 Two (N)-entity-invocations can establish (N-1)- 
connection(s), or can make use of an (N-l)-connection- 
less service, to support an (N)-associadon. The lifetime 
of an (N)-association may exceed the lifetime of any 
supporting (N-l)-connection(s). The binding of an (N)- 
association with (N-l)-connection(s) may change with 
time. 

NOTE - An (N)-association could be associated with a sequence 
of (N-l)-connections with a one-to-one binding at any point in 
lime; alternatively in the case of splitting, there could be a one- 
to-many binding at any point in time. 



7.1.5 When the operation of an (N)-association re- 
quires it, (N)-entity-tides are used to identify (N)-entities 
independent of their locations. When the operation of 
an (N)-association requires it, (N-l)-addresses are used in 
requests for (N-l)-services to identify the locations of the 
(N)-entities concerned. 



7.2 Attachment of (N)-entities to (N)- 
SAPs 

An (N)-entity may provide (N)-serviccs through one or 
more ^)-SAPs and may use (N-l)-services through one 
or more (N-l)-SAPs. In consequence an (N)-entity may 
have the following relationships with (N)-SAPs and (N- 
l)-SAPs (see Figure 1): 

a) an (N)-entity may provide (N)-services 
through one (N)-SAP making use of (N-l)-services 
through one (N-l)-SAP; 

b) an (N)-entity may provide (N)-services through 
multiple (N)-SAPs making use of (N-l)-services 
through one (N-l)-SAP; 

c) an (N)-entity may provide (N)-services 
through one (N)-SAP making use of (N-l)-services 
through multiple (N-l)-SAPs; 

cO an (N)-entity may provide (N)-services 
through multiple (N)-SAPs making use of (N-1)- 
services through multiple (N-l)-SAPs; 

NOTES 

1 There is no relationship between the SAP/entity corre- 
spondences identified above and multiplexing. An (N)-multi- 
plexing function provides for the mappinje of several (N)- 
connections onto a single (N-l)-connection. The (N)-connections 
may all terminate in a single (N)-SAP or they may terminate in 
separate (N)-SAPs. Multiplexed (N)-connections are distin- 
guished from each other by elements of (N)-PCI at the service 
boundary and by elements of the (N)-PAI, e.g. an association- 
identifier within the (N)-protocol. 

2 Logical channel numbers in X.25 (ISO 8208) and connection 
references in ^he OSI Transport Protocol (ISO 8073) are 
examples of information exchanged in (N)-PCI to distinguish 
connections when multiplexing is used. 



7.3 (N)-addresses and (N).SAPs 
7.3.1 The OSI addressing structure aUows: 

a) (N)-addresses to identify the location of an 
(N+l)-entity without constraining the structure of 
lower layer subsystems in the open system con- 
cerned; and 

b) multiple (N)-entities to be defined within an 
(N)-subsystem. 
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(N-1)-SAP 
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(N)-SAP 



(N)-SAP's 





(N-l)-SAP's 
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Figure 1 — Relationships of (N)-entity to (N)-SAPs and to (N-D-SAPs 
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NOTE - The relevant addressing structure allows a presentation- 
address to identify the location of an application-entity without 
constraining the structure of presentation-, session-, and 
transport-suDsystems within an open system; and allows the 
definition of a single set of addressing information for use in 
establishing commimication with an application-entity in a 
recipient system. 

7.3.2 An (N)-address identifies a set of (N)-S APs all 
located at the boundary of a single (N)-subsysteni. The 
exact membership of the set is an issue local to that 
(N)-subsystem. The set membership is not known to 
other open systems and may change over time. 

7.3.3 The set of (N)-S APs identified by an (N)-address 
may consist of: 

a) a single (N)-SAP bound to an (N+l)-entity; or 

b) multiple (N)-SAPs that are bound to a single 
(N+l)-entity; or 

c) multiple (N)-SAPs that are bound to different 

(N+l)-entities. 

7.3.4 When an (N)-address is used as a called-(N)-ad- 
dress in a service primitive, the recipient (N)-subsystem 
will select a single (N)-SAP from the set identified by 
the (N)-address. The selection mechanism is a local is- 
sue transparent to the (N)-initiator. 

7.3.5 Open systems are configured to enstu-e that all 
of the (N)-S APs in the set identified by an (N)-address are 
bound to (N+l)-entities that are of the same type and, 
therefore, provide the same functions. 

7.3.6 It is important to distinguish between the se- 
mantics of an (N)-address and the syntax used to represent 
an (N)-address within a given open system. ^)-ad- 
dresses are passed across layer boundaries within open 
systems as parameters of (N)-service primitives. For 
(N)-service request/response primitives, the semantics of 
(N)-addresses are conveyed to the peer (N)-subsystem and 
passed across the layer tx)undary as parameters of the (N)- 
service indication/confirm primitives. Only the seman- 
tics of an (N)-address are conveyed by the (N)-service. 
The syntax of an (N)-address is a local issue and different 
representations may be used in different open systems. 

7.3.7 When an (N+l)-entity establishes an (N)-con- 
nection with another (N+l)-entity, each (N+l)-entity is 
given an (N)-connection-endpoint-identifier [(N)-CEPI] 
by its supporting (N)-entity. (See 5.4,2 of ISO 7498). 
An (N)-CEPI is a local identifier determined at 
connection establishment time. An (N)-CEPI cannot be 
used as a substitute for an (N)-address. In the case that 
the calling-(N)-address and called-(N)-address of an (N)- 
connection are identical, the (NO-conneclion has two (N)- 
conn^jction-end-poinis and two (N)-CEPIs (connection of 
an(]Sr)-entity to itself). How the two (N)-CEPIs in the 



(N)-subsystems are distinguished is an entirely local 
matter. 



7.4 (N)-directory-functions and directory 
facilities 

7.4.1 (N)-dircctory-functions process (N)-addresses. 
(N-l)-addresses, (N)-entity-titles, and (N)-PAI to provide 
mappings among these categories of information. Infor- 
mation used for these mappings is held by a Directory 
Facility. It is a local system management responsibility 
to access the Directory Facility to retrieve the informa- 
tion and make it available to an (N)-directory-function. 

7.4.2 Some of this information represents the logical 
structure of the local end system and influences local 
operation. This information is stored locally. Other 
information represents the logical structure of the remote 
end system and influences the generation of (N)-PAI. 
This i^Jformation may be stored locally or remotely. If 
it is stored remotely, OSI protocols are used to access 
that information. 



8 Addressing information and (N)- 
services 

8.1 Introduction 

8.1.1 This clause provides a layer independent de- 
scription of the use of (N)-addresses in (N)-service 
primitives. 

8.1.2 (N+l)-entities use (N)-services by issuing (N)- 
service primitives at (N)-SAPs. Issuing an (N)-service 
request/response primitive may cause an (N)-service 
indication/confirm primitive to be issued at an (N)-SAP 
to which a peer (N+l)-entity is attached. 

8.1.3 The (N)-address derived from information pro- 
vided by a Directory Facility may be invalid. An (N)- 
address derived from the calling/ responding-(N)-address 
parameter of a previously received (N)-service indica- 
tion/confirm primitive has to be valid at the time it is 
issued, but no guarantee can be given for a subsequent 
use of this address. Therefore, an (N+l)-entity using an 
(N)-address should, under all circumstances, check that it 
has led to communication with the desired correspondent 
in the (N+l)-layer. It is normally sufficient to do this in 
the Application Layer by exchanging application-entity- 
titles. 

8.1.4 The use of an (N)-add^ess is not sufficient by 
itself to identify a particular (N+l)-entity-invocation. 
An (N+l)-entity may be satisfied to communicate with 
any (N+l)-entity-in vocation of the desirefl (N+l)-entity 
at the (N)-address. In some (N+l)-layers, it may be nec- 



11 



IS 12373 ( Part 3 ) : 1992 
ISO 7498-3 : 1989 



essary to reference the (N+l)-entity-invocation using the 
(N+l)-entity-invocation-identifier. 



8.2 Address parameters 

8.2.1 It is important to distinguish between the (N)- 
addresses passed as called-(N)-address paranieters and 
those passed as calling-(N)-address or responding-(N)-ad- 
dress parameters. 

8.2.2 Called-(N)-addresses are used in the initiation of 
communication between (N+l)-entity-invocations. The 
(N+l)-initiator provides the called-(N)-address the se- 
mantics of which are conveyed to the peer (N+l)-recipi- 
ent. 

8.2.3 Calling- and responding-(N)-addresses are 
priinarily used for identification and recall purposes and 
may identify the specific (N)-SAPs used in an instance of 
communication. 



8.3 Called-(N)-address 

8.3.1 The called-(N)-address parameter in connection- 
mode service primitives is equivalent to the destination 
(N)-address parameter in connectionless-mode service 
primitives. 

8.3.2 The called-(N)-address is provided by the (N+1)- 
initiaior. The semantics of the (N)-address are conveyed 
to the recipient (N)-subsystem and passed to the (N+1)- 
subsystem in an (N)-scrvice indication primitive. 

8.3.3 The called-(N)-address conveyed in the (N)-ser- 
vice indication primitive parameter is not restricted to 
be the same address as was specified in the associated 
request primitive. However, an (N)-service definition 
may impose such a restriction. 

8.3.4 Above the Network L^yer, address processing is 
confined to end systems: 

a) at the initiating open system, the processing of 
the caIled-(N)-address is not dependent on the com- 
plexity of the address structures supported by the 
recipient open system; and 

b) at the recipient open system, the processing of 
the called-(N)-address depends on the complexity of 
the address structures supported by this system. 

8.3.5 In the Network Layer, although some process- 
ing of the called-(N)-address may occur in an intermediate 
system, this processing is not dependent on the com- 
plexity of the address structures supported by the recipi- 
ent open system. 



8.3.6 The cailed-(N)-address identifies a set of (N)- 
SAPs at the recipient-(N)-subsystem. Any one of the 
(N)-SAPs in this set may be used to support the 
communication. The resolution of the address to select a 
particular (N)-SAP is the responsibility of the recipient 
(N)-subsystem. 

8.3.7 The called-(N)-address may have been derived 
from infonnation obtained from the Directory Facility. 
In this case, the semantics of the (N)-address are related 
to a directory entry published on behalf of the recipient 
system. The attributes associated with the Directory Fa- 
cility entry are known within the recipient system. The 
called-(N)-address identifies a set of (N)-SAPs that pro- 
vide access to (N+l)-entities which support com- 
munication in a manner that is consistent with the 
information obtained from the Directory Facility. 

8.3.8 The called-(N)-address may have been previously 
passed as a calling- or responding-(N)-address parameter 
by the recipient (N)-subsystem in a previous instance of 
communication. In this case, the (N)-address identifies 
the set of (N)-SAPs consistent with the rcquiremcnis 
concerning calling- or rcsponding-(N)-addresses descrilxxl 
in clauses 8.4 and 8.5. 

8.3.9 The called-(N)-address may have been obtained 
by private arrangement. In this case, the called-(N)-ad- 
dress identifies a set of (N)-SAPs that provide access to 
(N+l)-entities that support communication in a miinner 
consistent with that private arrangement. 



8.4 CalHng-(N)-address 

8.4.1 The cailing-(N)-address parameter in connection- 
mode service primitives is equivalent to the source (N)- 
address parameter in connectionless-mode service primi- 
tives. 

8.4.2 The calling-(N)-address is provided by the 
(N-f-l)-initiator. The semantics of the (N)-address are 
conveyed to the recipient (N)-subsystem and passed to 
the (N+l)-subsystem in an (N)-service indication primi- 
tive. 

8.4.3 Provided (N)-protocol specifications and OS I 
management standards do not impose constraints, the 
recipient (N4-l)-subsystem may use the calling-(N)-ad- 
dress in any of the following ways: 

a) as a called-(N)-address in a subsequent request 
primitive that is not related to the initial 
communication; 

b) as a called-(N)-address in a subsequent request 
primitive that is related to the initial communica- 
tion, in order to facilitate connection re-establish- 
ment or splitting; ♦ 
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c) as a called-(N)-address which is forwarded to 
some other open system; 

(5 for management purposes. 

8.4.4 While valid, the calling-(N)-address will identify 
a set of (N)-SAPs at the initiating (N)-entity. The set of 
(N)-S APs identified may be constrained by layer specific 
requirements concerning calling-(N)-addresses. For 
example, a layer may require a calling-(N)-address to 
identify the single (N)-SAP actually used to support the 
original communication. 

8.4.5 When the calling-(N)-address received in an (N)- 
service indication primitive is used by the recipient (N)- 
subsystem as a called-(N)-address in a subsequent (N)- 
service request primitive, this subsystem should be aware 
of the possibility that this address may be no longer 
valid in the sense defined in 8.4.4 and should take 
appropriate measures. 



8.5 



Responding-(N)-address 



8.5.1 The responding-(^^)-address is used in (N)-service 
response/confirm primitives. 

NOTE - in some OSI service definitions the term "called address" 
is used in response and confirm primitives to denote the re- 
sponding-(N)-address parameter. 

8.5.2 The responding-(N)-address is provided by the 
(N+l)-recipient. The semantics of the (N)-address are 
conveyed to the initiating (N)-subsystem and passed to 
the initiating (N+l)-subsystem in a confirm service 
primitive. 

8.5.3 Provided (N)-layer protocol specifications and 
OSI management standards do not impose constraints, 
the initiating (N+l)-subsystem may use the resporiding- 
(N)-address in any of the following ways: 

a) as a called-(N)-address in a subsequent request 
primitive not related to the initial communication; 

b) as a called-(N)-address in a subsequent request 
primitive related to this communication, e.g. to fa- 
cilitate connection re-establishment or splitting; 

c) as a called-(N)-address which is forwarded to 
some other open system; 

c5 for management purposes. 

8.5.4 The responding-(N)-address may differ from the 
called-(N)-address specified in the related (N)-service 
indication primitive. 

8.5.5 While valid, the responding-(N)-address will 
identify a set of (N)-SAPs at the recipient (N)-entity. 
The set of (N)-SAPs identified may be constrained by 



layer specific requirements concerning responding-(N)- 
addresses. For example, a layer may require a respond- 
ing-(N)-address to identify the single (N)-SAP actually 
used to support the communication. 

8,5.6 When the responding-(N)-address received in an 
(N)-service confirm primitive is used by the initiating 
(N)-subsystem as a called-(N)-address in a subsequent 
(N)- service request primitive, this subsystem should be 
aware of the possibility that this address may be no 
longer vahd in the sense defined in 8.5.5 and should take 
aj^ropriate measures. 



9 Addressing 
protocols 

9.1 Introduction 



information and (N)- 



This clause provides a layer independent description of 
the use of addressing information in (N)-Protocol-Ad- 
dressing-Information [(N)-PAI]. (N)-PAI are those el- 
ements of (N)-PCI which contain addressing information. 



9.2 Addressing information in (N)-PAI 

9.2.1 The semantics of an (N)-address are conveyed by 
means of (N)-protocol exchanges between (N)-entity- 
invocations. For some layers, the full semantics of (N)- 
addresses are conveyed in (N)-PAL In other layers, it is 
not necessary for the full semantics of (N)-addresses to be 
represented in the (N)-PAI and, for these layers, the full 
semantics of (N)-addresses are conveyed by a combina- 
tion of: 

a) the exchange of (N)-PAI; and 

b) local information about the scope of the (N)-PAI. 

NOTES 

1 For example, the network-entities exchange network-addresses. 
In this case, the Network-PAI includes the network-address. 

2 The values of (^^)-PAI may include information relevant to the 
operatioTi of both the (N)-layer and the (N+l)-layer. Neverthe- 
less, a given layer only makes use of the information relevant to 
that layer. 

9.2.2 Below the Network Layer, communicating (N)- 
entities are confined to a single subnetwork. The (N)- 
PAI exchanged need not be globally applicable, since it 
can be interpreted within the scope of the subnetwork. 

9.2.3 At the Network Layer, communicating (N)-en- 
tities may be attached to different subnetworks. Conse- 
quently, the (N)-PAI exchanged has to be globally appli- 
cable. For this reason, the Network-PAI^ alone provides 
for the exchange of the complete semantics of a network- 
address. 



13 



IS 12373 ( Part 3 ): 1992 
ISO 7498-3 : 1989 



9.2.4 Above the Network Layer, the scope of the (N)- 
PAI is restricted to the communicating end systems. At 
these layers, the semantics of the (N)-^address comprise: 

a) the identification of a set of (N)-SAPs; this 
identification is unambiguous within the scope of 
the (N)^ubsystem which contains the (N)-SAPs and 
is provided by ^)-selectors exchanged in (N)-PAI 
and local information about the scope of the (N)-se- 
lectors within the (N)-subsystem; and 

b) the identification of the end systems, derived 
from the Network Layer exchange of network-ad- 
dresses. 

NOTE - At the Application Layer, titles and identifiers, not ad- 
dressing information, are exchanged. 



9.3 Assignment of values to elements of 
(N).PAI 

9.3.1 Layer protocol specifications define elements of 
(N)-PAI to be used for the exchange of addressing 
information. Different elements of (N)-PAI are used to 
convey the semantics of: 

- called-(N)-addresses, 

- calling-(N)-addresses, and 

- rc^x)nding-(N)-addresses. 

9.3.2 The values of the elements used to convey 
calling-(N)-address semantics are provided by the (N)- 
initiator. These values may be retained by the recipient 
(N)-subsystem and used in a subsequent request primitive 
to convey called-(N)-address semantics to the original 
initiating (N)-subsystem. 

9.3.3 The values of the elements used to convey re- 
sponding-(N)-address semantics are provided by the re- 
cipient (N)-subsystem. These values may be retained by 
the initiating (N)-subsystem and used in a subsequent 
(N)-service request primitive to convey called-(N)-address 
semantics to the recipient (N)-subsystem. 

9.3.4 The values of the elements used to convey called- 
(N)-address semantics may be obtained: 

a) from a Directory FaciUty, 

b) by private arrangement, or 

c) from previously issued (calling-) responding- 

(N)-addresses, 



9.4 Network-addresses and network-PAI 

The complete semantics of the network-address is con- 
veyed in the Network-PAL The network-address is 
globally applicable and is issued by the appropriate 
registration authority. 



9,5 (N)-Addresses and (N)-PAI above the 
Network Layer 

9.5.1 (N)-selectors are unambiguous within the scope 
of an (N)-subsystem. The values of (N)-selectors are 
chosen by the local administration of an open system and 
there is no requirement for an OSI addressing authority, 
although the chosen values has to be known by systems 
which want to communicate. When an (N)-selector iden- 
tifies a set of (N)-SAPs, the resolution of that (N)-selec- 
tor is the responsibility of the recipient (N)-subsystem. 

NOTES 

1 All (N)-entilies refer to a particular set of (N)-SAPs in the 
same way, H.e. the (N)-selecU)r value which is associated with 
this set of (N)-SAPs is the same regardless of the (N)-entity 
which handles the communication). 

2 The way unambiguity is achieved is a local matter. Local 
administration of the open system may decide to achieve that 

goal by defining (N)-selectors that are unique within the scope of 
le (N)-subsystem. In such a case, the semantics of the (N)- 
selector is directly derived from the value carried in the (N)-rAl, 
regardless of the (N)-entity which handles the communication, 
where (N)"Selectors are unambiguous within the scope of the (N)- 
subsystem, without being unique within that scope, additional 
information local to the recipient open system, is necessary ^in 
particular, the semantics of tne (N)-selector depend on the (N)- 
entity which handles the communication). 

9.5.2 Protocol specifications may designate (N)-PAI as 
optional and therefore it may be absent. Since the (N)- 
PAI in an (N)-protocol is the (N)-selector, the (N)- 
selector may be absent. There is no distinction between 
the absence of an (N)-selector and the presence of a nil 
(N)-selector value in connectionless-mode operation. In 
connection mode operation, the absence of an (N)-selec- 
tor is equivalent to the presence of a nil (N)-selector 
value for calling- and called-(N)-addresses. For respond- 
ing-G^-addresses, the absence of an (N)-selector indicates 
that the responding-(N)-address is equivalent to the called- 
(N)-address. 

NOTE - Within layers which use the Type-Length- Value (TLV) 
encoding technique: 

a) "absence of selector" means that no parameter of the 
type used to eonvey this selector is present; 

b) the "nil selector value " corresponds to a zero value for 
the length field of the parameter which is of the type used to 
convey this selector; and 

c) if the parameter type which corresponds to the type 
used to convey the selector is present and if the associated 
parameter length is not zero, tnen the selector value is not 
considered as nil whatever the encoding of this value might 
be. ♦ 



14 



IS 12373 ( Part 3 ) : 1992 
ISO 7498-3 : 1989 



9.5,3 The nil (N)-selector value (or the absence of a 
value) is only used in (N)-PAI to convey called-(N)-ad- 
dress semantics when the nil value has been specified: 



a) 
or 



by a value from an entry in a Directory Facility; 



b) as the (N)-PAI used to convey the sen^ntics of 
a previously issued calUng/responding-(N)-address; 
or 

c) by private arrangement 

9.5,4 The (N)-recipient uses the nil (N)-selector value 
according to local information to select an (N)-SAP. 

NOTE - The use of a nil (N)-seleclor value does not preclude the 
use of other (N)-selector values by the local administration of an 
open system. 



9.6 Obtaining (N)-PAI 

9.6.1 Information about application-entities is obtain^ 
from the Application Title Directory Facility (see clause 
14). Included in this information is a single tuple 
specifying the addressing (N)-PAI values required to ac- 
cess the application-entities through a PSAP.^ The tuple 
is of the form: 

(P-selector, S-selector, T-selector, list of Network-ad- 
dresses) 

NOTE - Each of the (N)-PAI values derived from the tuple may 
be used by the relevant (N)-recipient to identify a set of (N)- 
SAPs. The fact that the (N)-addressing information may identify 
a set of (N)-SAPs is known only by the recipient (N)-subsystem. 

9.6.2 All of the network-addresses of the list belong to 
a single open system. At the initiating open system, 
one of the network-address values is selected by local 
system management for a given instance of communi- 
cation. 

9.6.3 The T-selector is the single T-selector value that, 
when used in transport-PAI, identifies the set of TSAPs 
at the open system to which the set of network-addresses 
in the tuple applies. The selector value is equally valid 
regardless of which network-address is used. 

9.6.4 The S-selector is the single S-selector value that, 
when used in session-PAI, identifies the set of SSAPs at 
the open system to which the set of network-addresses in 
the tuple applies. The selector value is equally valid re- 
gardless of which network-address is used. 

9.6.5 The P-selector is the single P-selector value that, 
when used in presentation-PAI, identifies the set of 
PSAPs at the open system to which the set of network- 
addresses in the tuple iipplies. The selector value is 
equally valid regardless of which netwak-addiess is used. 



1 (N)-directory-functions 

10.1 Introduction 

10.1.1 (N)-directory-functions process (N)-addresses, 
(N-l)-addresses, (N)-entity-tides, (N)-PAI. and possibly 
routing information to provide mappings among these 
categories of information. These functions are perform^ 
by the (N)-entity within the (N)-layer during connection 
establishment or connectionless data transmission: 

a) when an (N)-service request primitive is received 
from the (N+l)-layer, or an (N-l)-service con- 
firmation primitive is received from the (N-l)-layer 
(the initiator (N)-du-ectory-functions); and 

b) when an (N-l)-service indication primitive is 
received from the (N-l)-layer, or an (N)-service re- 
sponse primitive is received from the (N+l)-layer 
(the recipient (N)-directory-funcUons). 

10.1.2 Information on these mappings may be held 
by local system management and made available for ac- 
cess by (N)-directory-functions or it may be held by a 
Directory Facility. If information is needed from a Di- 
rectory Facility, it is obtained by local system manage- 
ment and made available to (N)-directory-functions. 

10.2 The initiator (N)-directory-functioiis 

10.2.1 The parameters of the initiator (N)-directory- 
functions used for connection establishment or connec- 
tionless data transmission are: 

a) the called- (N) -address supplied by the (N44)- 
layer, (CALLED-(ISj-ADDRESS); 

b) the calling-(N)-address supplied by the (N+1)- 
layer, (CALLING-^- ADDRESS); 

c) the called-(N)-entity-title supplied by the (N)- 
layer, (CALLED-(N)-E>mTY-TITLE); 

d) die caIled-(N- l)-address generated by an initiator 
(N)-directory-function, (CALLED-(N-l)-AD- 
DRESS); 

e) the responding-(N)-PAI supplied by the (N-1)- 
layer, (RESPONDING-(N)-PAI); 

f) the responding-(N-l)-address supplied by the (N- 
l)-layer,(RESPONDING-(N-l)-ADDRESS); and 

g) information (LOCAL) made available by local 
system management to the (N)-directory-functions 
on loading, quality of service requirements, and other 
local information. 
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NOTE - A layer need not use all of these parameters for its 
initiator (N)-diiectory-fijnctions. 

10.2.2 Taking these parameters as input the initiator 
(N)-directory-functions generate the following informa- 
tion: 

a) the called-(N)-PAI to be carried in (N)-PCI. 
(CAIXED-(N)-PAI): 

b) the calling-(N)-PAI to be carried in (N)-PCI, 
(CALLING-{N)-PAI); 

c) the calling-{N-l)-audress to be passed in the (N- 
l)-service request primitive, (CALLING-(N-1)- 
ADDRESS); 

NOTE - The choice of the (N-l)-SAP at which this (N-1)- 
service request primitive is issued is a local matter. This 
choice has to be consistent with the calling-(N-l)-address. 

c5 the called-(N-l)-address to he passed in the (N- 
l)-service-request-primitive, (CALLED-(N-1)- AD- 
DRESS); and 

e) the responding-(N)-address to be passed in the 
(N)- service confirmation primitive, 
(RESPONDING-(N)-ADDRESS); 

f) routing information, (ROUTING IN- 
FORMATION). 

NOTE - The nature of the ROUTING INFORMATION and 
its use by the (N^-layer depend on the detailed architecture of 
the routmg function withm the (N)-layer. 

10.2 J There are seven initiator (N)-directory-functions. 

a) The Initiator Addressing Function i - lAFl. 
For this function, 

1) the input parameters are: CALLED-(N)- 
ENTITY-TITLE and LOCAL; 

2) the output is: CALLED-(N-1)-ADDRESS. 

b) The Initiator Addressing Function 2 - IAF2. 
For this function, 

1) the input parameters are: CALLED-(N)-AD- 
DRESS and LOCAL; 

2) the output is: CALLED-(N-i)-ADDRESS. 



(D The Initiator Addressing Function 4 - IAF4. 
For this function, 

1) the input parameters are: RESPONDING- 
(N-1)- ADDRESS and RESPONDING-(N)-PAI; 

2) the output is: RESPONDING-(N)-AD- 
DRESS. 

e) The Initiator PAI Function I - IPFl. For this 
function, 

1) the input parameter is: CALLED-(N)-AD- 
DRESS; 

2) the output is: CALLED-(NO-FAL 

f) The Initiator PAI Function 2 - IPF2, For this 
function, 

1) the input parameters is: CALLING-(N)- 
ADDRESS; 

2) the output is: CALLING-(N)-PAI. 

g) The Initiator Routing Function 1 - IRFl. 
For this function, 

1) the input parameters are: CALLED-(N)- 
ADDRESS and LOCAL; 

2) the output is: ROUTING INFORMATION. 



10.3 The recipient (N)-directory-functions 

i0*3,i The parameters of the recipient (N)-directory- 
functions used for connection establishment or 
copji^tionless data transmission are: 

a) the calied-(N-l)-address supplied by the (N-1)- 
layer, (CALLED-(N-l)-ADDRESS); 

b) the caliing-(N-i)-address supplied by the (N-i)- 
layer, (CALLING-(N-1)- ADDRESS); 

c) the called-(N)-PAI carried in the (N)-PCI, 
(CALLED-(N)-PAI); 

(H the calling-(N)-PAI carried in the (N)-PCI, 
(CALLING-CNl-PAI); 



c) The Initiator Addressing Function 3 - IAF3. 
For this function, 

1) the input parameters are: CALLED-(N-l)- 
ADDRESS, CALLING-(N)-ADDRESS and 
LOCAL; 



e) the responding-(N)-address supplied by the 
(N+l)-layer, (RESPONDING-(N)- ADDRESS); and 

f) information (LOCAL) locally known, identifying 
the scope of (N)-PAI. 



2) the output is: CAXLING-(N-1)-ADDRESS. 
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NOTE - A layer need not use all of these parameters for its 

recipient (N)-directory-functions. 

10.3.2 Taking these parameters as input the recipient 
(N)-direcloryifunctions generate the following inform- 
ation: 

a) the called-(N)-address to be passed in the (N)- 
service indication primitive, (CALLED-(N)-AD- 
DRESS); 

NOTE - The choice of the (N)-SAP at which this (N)-scivice 
indication primitive is issued is a local matter. This choice 
must be consistent with the called-(N)-address. 

b) the calling-(N)-address to be passed in the (N)- 
service indication primitive (CALLING-(N)-AD- 
DRESS); 

c) the responding-(N-l)-address to be passed in the 
(N-l)-service response primitive, (RESPONDING- 
(N-l)-ADDRESS);and 

d) the responding-(N)-PAI carried in (N)-PCI, 
(RESPONDING-(N)-PAI). 

10.3.3 There are four recipient (N)-direciory-functions. 

a) The Recipient Addressing Function 1 - RAFl. 
For this function, 

1) the input parameters are: CALLED-(N)- 
PAI, CALLED-(N-1)-ADDRESS, and LOCAL; 

2) the output is: CALLED-(N)-ADDRESS. 

b) The Recipient Addressing Function 2 - RAF2. 
^or this function, 

1) the input parameters are: CALLING-(>P 
PAI and CALLING-(N-1)-ADDRESS; 

2) the output is: CALLING-(N)-ADDRESS. 

c) The Recipient Addressing Function 3 - RAF3, 
For this function, 

1) the input parameters are: CALLED-(N-l)- 
ADDRESS and LOCAL; 

2) the outpiii is: RESPONDING-(N-l)-AD- 
DRESS. 

d) The Recipient PAI Function - RPFl. For this 
function, 

1) the input parameter is: RESPONDING-(N)- 
ADDRESS; 

2) the output is: RESPONDING-(N)-PAI. 



1 1 Addressing in specific OSI layers 

11.1 Application-processes and the Applica- 
tion Layer 

This clause is concerned with the naming of elements of 
Application-processes and the Application Layer. A 
complete description of these elements is given in ISO 

9545. 

11.1.1 Application-processes an^d Applica- 
tion Layer elements 

11.1.1.1 Application-processes are identified by ap- 
plication-process-titles that are unambiguous throughout 
the OSIE. An application-process-tide is a single name 
which, for convenience, may be structured internally. In 
particular, for some application-processes' the internal 
structure of the application-process-title may be based on 
system-title. 

NOTES 

1 The purpose of structuring an apphcation-process-title froni a 
system-lilie is to make it possible to register application- 
processes within the system on which they reside once its 
system-tide has been registered. 

2 Application-process-titles can have synonyms. That is, an 
application-process may be known to one or more application- 
processes by different applicadon-process-titles. 

11.1. L 2 Application-entities are identified by ap- 
plication-entity-titles thM are unambiguous throughout 
the OSIE. An application-entity-title is composed of an 
application-process-title and an application-entity-quali- 
fier. This division into two components pem^its the 
user of the application-entity-title to obtain information 
specific to the applicauon-process or to the application- 
entity. The application-entity-qualifier is unambiguous 
within the scope of the applicationrprocess. Each 
application-entity-title is associated wiu^ a presentation- 
address. 

NOTE - Application-entity-titles can have synonyms. That is, 
an application-entity ma^ be known to one or more application- 
entities by different apphcadon-endty-tides. 

li,l.l,3 Where application-process-invocations have 
to be identified, this is done by means of application- 
process-invocation-identificrs that are unambiguous 
within the scope of an application-process. An apphca- 
tion-process-invocation is identified unambiguously 
within the OSIE by the application-process-invocation- 
identifier qualified by the application-process-tiUe. 

11,1.1,4 Where application-endty-invocations have 
to be identified, this is done by means of application-en- 
tity-invocation-identifiers that are unambiguous within 
the scope of a pair: (application-process-invocation, 
application-entity). An application-entity-invocation is 
identified unambiguously within the OSIE ty the appli- 
cation-entity-invocation-identifier qualified by the appli- 
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cation-entity-qualifier, the application-prcx^ess-invoca- 
tion-identifier. and the application-process-titlc. 

NOTE - The following table provides a summary of the 
identifiers described above: 



11 bM Identified bViE 


"ATT 


APII 


ABcr 


"ssr 


AddI. Process 


+ 








ApdI. Process Invocation 


+ 


+ 






AddI. Entity 


+ 




+ 




Appl. Entity Invocation 


+ 


+ 


+ 


+ 



AFT = a^^lication-process-title 

APn = application-process-invocadon-identifier 

ABQ = application-entity-qualifier 

AEU = a|]plication-entity-invocation-identifier 

ll.U.S Where application-associations have to be 
identified, this is done by means of application-associa- 
tion-identifiers that are unambiguous within the scope of 
the application-entity-invocations at the endpoints of the 
association. 

11.1.1.6 Where application-process-types have to be 
identified, this is done by means of an application-pro- 
cess-type-title that is unambiguous throughout the 
OSIE. An application-process-type-title may be used to 
denote the distributed processing capabilities of an appli- 
cation-process. 

11.1.1.7 Where application-entity-types have to be 
identified, this is done by means of an application-entity- 
type-title that is unambiguous throughout the OSIE. 
An application-enuty-type-title may be used to denote 
the communications capabilities of an application-entity. 

11.1.1.8 At any instant of time, each application-en- 
tity-title is bound to a single presentation-address that 
identifies the set of PS APs to which the apphcation-en- 
tity is attached. This binding is recorded in the 
Application Title Directory Facility (see clause 14). 

11.1.2 AppHcation-associatlon 

11.1.2.1 In order for an application-entity-invocation 
to establish an application -association with another 
application-entity-invocation, it uses the presentation- 
address of the called application-entity to establish a pre- 
sentation-connection or to use the presentation connec- 
tionless-mode service. This presentation-address may be 
obtained from the application-directory-function, lAFl, 
using the called-application-entity-title. 

11.1.2.2 If it is necessary to confirm that the required 
application-entity is still attached to the PSAP identified 
by the presentation-address, then the initiating applica- 
tion-entity-invocation may pass the called-application- 
entity-title as a part of the application-PCI exchanged to 
establish the application-association. 

11.1.2.3 Application-entity-invocations may ex- 
change calling- and responding-application-entity-tities 



for use in future communication. Such titles may be 
recognized by a recipient system as naming specific re- 
sponding-application-entities. This is a matter for 
agreement between the communicating applications. 

11.1.2.4 If required in establishing an application- 
association, the application-entity-invocations may ex- 
change the following identifiers as part of the applica- 
tion-PCI exchanged to establish the application-asso- 
ciation: 

- application-process-invocation-identifier, 

- application-entity-invocation-identifier, 

- application-association-identifier . 



11.1.3 Application 

rectory-functions 



Layer use of (N)-di- 



11.1.3.1 In the initiating system, on request from the 
application-process, the application-entity : 

a) uses lAFl to derive the called-presentation-ad- 
dress (which is passed in a presentation-service re- 
quest primitive) from the called-application-entity- 
title and from local information; and 

b) uses IAF3 to derive the calling-presentation-ad- 
dress (which is passed in a presentation-service re- 
quest primitive) and the local PSAP through which 
the presentation-service request primitive is issued 
from the called-prescntation-address and from local 
information. 

NOTES 

1 The choice of the PSAP at which this primitive is 
issued is a local matter. This choice has to be consistent 
with the calJing-presentation-acJdiess. 

2 At the Application Layer, the calling-(N)-address 
parameter does not apply. 

11.1.3.2 The initiator application-directory-function, 
lAFl, yields a single presentation-address. Where a 
generic application-entity-titie (e. g., application-entity- 
type-title) is used as the called-application-entity-title, 
resolution of this tiUe to a single presentation-address is 
the responsibility of the recipient local system, 

11.1.3.3 In the recipient system, on receipt of a 
presentation-service indication primitive, the application- 
entity uses RAF3 to derive the responding-presentation- 
address from the called-presentation-address and from lo- 
cal information. 



11.2 Presentation Layer 

11.2,1 In the initiating system, on receipt of a pre- 
sentation-service request primitive, the presentation-en- 
tity: 
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a) uses IAF2 to derive a called-session-address 
(which is passed in a session-service request primi- 
tive) from the called-presentation-address and from 
local information; 

b) uses IAP3 to derive the calling-session-address 
(which is passed in a session-service request primi- 
tive) and the local SSAP through which the session- 
service request primitive is issued from the called- 
session-address, the calling-presentation-address, and 
local information; 

NOTE - Tlie choice of the SSAP at which this primitive is 
issued is a local matter. This choice has to be consistent 
with the calling-session-address. 

c) uses IPFl to derive the called-presentation- 
selector, (which is sent in presentation -PAI), from 
the called-presentation-address; and 

d) uses IPF2 to derive the calling-presentation- 
selector, (which is sent in presentation -PAI), from 
the calling-presentation-address. 

11.2.2 In the recipient system, on receipt of a session- 
service indication primitive, the presentation-entity: 

a) uses RAFl to derive the called-presentation- 
address from the called-presentatiohr«elector (which 
is received in presentatiqn-PAI) the called-session- 
address, and from local information; 

NOTE - Local informa, 'on may be used to resolve a called- 
presentation -selector, "^t refers to a set of PSAPs to a 
single PSAP. 

b) uses RAF2 to derive the callu j-presentation- 
address from the calling-presentation-selector (which 
is received in presentation-PAI) and from the calling- 
session-address; 

c) uses RAF3 to derive the responding-session- 
address fix)m the called-session-address and from local 
information; and 

d) uses RPFl to derive the respon ding-pre- 
sentation-selector (which is sent in presentation- 
PAI) from the responding-presentation-ad^lress 
(which is received in a presentation-service response 

primitive). 

11.2.3 In the initiating system for connection-mode 
operation, on receipt of a session-service confirmation 
primitive, the presentation-entity uses IAF4 to derive the 
responding-presentation-address from the responding- 
presentation-selector (which is received in presentation- 
PAI) and from the responding-session-address received 
from the session-service confirmation primitive. 



11.3 Session Layer 

11.3.1 In the initiating system, on receipt of a ses- 
sion-service request primitive, the session-entity: 

a) uses IAF2 to derive a called-transport-address 
(which is passed in a transport-service request 
primitive) from the called-sess'on-address and from 
local information; 

b) uses IAF3 to derive the calling-transport-address 
(which is passed in a transport-service request 
primitive) and the local TSAP through which the 
transport-service request primitive is issued from 
the called-transport-address, the calling-session-ad- 
dress and local information; 

NOTE - The choice of the TSAP at which this primitive is 
issued is a local matter. This choice has to be consistent 
with the calling-transport-address. 

c) uses IPFl to derive the called-session-selector 
(which is sent in session-PAI) from the called-ses- 
sion-address; and 

(I) uses IPF2 to derive the calling-session-selector 
(which is sent in session-PAI) from the calling-ses- 
sion-address. 

11.3.2 In the recipient system, on receipt of a trans- 
port-service indication primitive, the session-entity: 

a) uses RAFl to derive the called-session-address 
from the called-session-selector (which is received in 
session-PAI), the called-transport-address, and from 
local information; 

NOTE - Lxx:al information may be used to resolve a called 
session-selector that refers to a set of session-SAPs to a 
single session-SAP. 

b) uses RAF2 to derive the calling-session-address 
from the calling-session-selector (which is received 
in session-PAI) and from the calling-transport-ad- 
dress; 

c) uses RAF3 to derive the responding-transport- 
address from the called-transport-address and from 
local information; and 

cl) uses RPFl to derive the responding-session-se- 
lector (which is sent in session-PAI) from the 
responding-session-address, which is received in a 
session-service response primitive. 

11.3.3 In the initiating system for connection-mode 
operation, on receipt of a transport-service confirmation 
primitive, the session-entity uses IAF4 to derive the re- 
sponding-session-address from the responding-session- 
selector (which is received in session-PAI) and from the 
responding-transport-address which is received in the 
transport-service confirmation primitive. 
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11.4 Transport Layer 

11.4.1 In the initiating system, on receipt of a trans- 
port-service request primitive, the transport-entity: 

a) uses IAF2 to derive a called-network-address 
(which is passed in a network-service r^uest primi- 
tive) from the called-transport-address and from local 
information; 

b) uses IAF3 to derive the calling-network-address 
(which is passed in a network-service request primi- 
tive) and the local NSAP through which the service 
primitive is issued from the calied-nen)V'ork=address, 
the calling-transport-address and local information; 

NOTE - The choice of the NSAP at which this primitive is 
issued is a local matter. This choice has to be consistent 
with the calling-network-address. 

c) uses IPFl to derive the called-transport-selector 
(which is sent in transport-PAi) from the calied- 
transport-address; and 

d> uses IPF2 to derive the calling-transport-selector 
(which is sent in transport-PAI) from the calling- 
trahsport-address. 

NOTE - The initiator transport-director^ -function IAr2 always 
yields a single network-address. Where the addressing 
mformation provided by the Application Title Directory Facility 
or by private arrangement specifies a Ust of network-addresses, 
resolution of these addresses to a single network-address is the 
responsibilities of local system management. (See 9.6.2). 

11.4.2 In the recipient system, on receipt of a net- 
work-service indication primitive, the transport-entity: 

a) uses RAFl to derive the called-transport-address 
from the called-transport-selector (which is received 
in a transport-PAI). the called-network-address, and 
from local information; 

NOTE - Lx>cal information may be used to resolve a called- 
transport-selector that refers to a set of ISAFs to a single 
TSAP. 

b) uses RAF2 to derive the calling-transport-ad- 
(hress from the calling-transport-selector (which is 
received in transport-PAI) and from the caliing-nel- 
woric-address; 

c) uses RAF3 to derive the responding-network- 
address from the called-network-address and from lo- 
cal information; and 

d) uses RPFl to derive the responding-transport- 
selector (which is sent in transport-PAI) from the 
responding-transport-address (which is received in a 
transport-service response primitive). 



11.4.3 In the initiating system for connection-mode 
operation, on receipt of a network-service confirmation 
primitive, the transport-entity uses IAF4 to derive the 
responding-transport-address from the responding-trans- 
port-selector (which is received in transport-PAI) and 
from the responding-network-address received in the net- 
work-service confirmation primitive. 



11.5 Network Layer 

11.5.1 introduction 

11.5.1.1 The internal architecture of the Network 
Layer is complex. At each higher layer of the OSI ar- 
chitecture, an instance of communication (i.e. com- 
munication over a connection-mode, or a connectionless- 
mode data transmission) involves only a single pair of 
peer entities, which are located in end systems and com- 
municate by means of a peer protocol. Within the Net- 
work Layer, however, communication often requires the 
participation of network-entities not only in the end sys- 
tem - but in intermediate systems as well. The necessary 
interactions between network -entities may be achieved 
through the operation of single protocols between pairs 
of network-entities, or may need more complicated com- 
binations of layered protocols within the Network Layer. 

11.5.1.2 The task of the network-directory-functions 
is, for any instance of communication, to use the called- 
and calling-network-addresses, together with other infor- 
mation, to determine which network-entities participate 
in the communication (this determination may be 
achieved by other methods). 

11.5.2 Properties of network-addresses 

11.5.2.1 Introduction 

The properties are stated in terms of network-addresses. 
Since netwoik-addresses refer to sets of NSAP-addresses, 
they extend naturally to a single NS AP-address. 



11.5.2,2 



Global non-ambiguity 



At any instant of time, a network-address identifies just 
one set of NSAPs in the global <iomain. A set of 
NSAPs may have more than one network-address, i.e., 
synonyms may exist. 

11.5.2.3 Gioba! applicability 

It is possible at any set of NSAPs to identify any other 
set of NSAPs, in any end system, by means of the net- 
work-address of the other set of NSAPs. If the other set 
of NSAPs has synonymous network-addresses, any of 
the synonyms will identify the set of NSAPs. In par- 
ucular, therefore. 
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a) a network-address identifies the same set of 
NSAPs whenever it is used: 

b) any network-address may be used anywhere to 
identify the same set of NSAPs; 

c) a network-service user, when it receives a caO- 
ing-network-address in a network-service indication 
primitive, may use that network-address in another 
instance of communication with that set of NSAPs. 

For a set of NSAPs with synonymous network-ad- 
dresses, in some circumstances the possibility of com- 
munication may depend upon which synonym is used. 

NOTE - The global applicability of network-addresses does not 
imply that a communication to a given set of NSAPs can always 
be made. Restrictions can occur because of lack of physical 
media, lack of directory (routing) information, security 
procedures, or charging requirements. 

11.5.2.4 Route independence 

Network-service users cannot derive routing information 
from a network-address. They cannot control the Net- 
wor4c Layefs choice of route by means of network-ad- 
dresses, i.e. by choice of synonym. Similarly they can- 
not deduce from the network-addresses the route that was 
used by the network-service provider. 

tl.5.3 Network-addresses and SNPAs 

11.5.3.1 Given the requirement to provide communi- 
cations between two sets of NSAPs, it is a Network 
Layer function to determine which network-entities have 
to participate and how they must operate together. In 
general this function requires the use of Network Layer 
Directory Facihties. 

11.5.3.2 Network-entities exist within end open sys- 
tems and intermediate systems. In the real world, end 
open systems are realized by real end systems; 
intermediate systems are realized by real subnetworks or 
by (real) interworking units. An important concept in 
the relationships between such equipment is that of the 
Subnetwork Point of Attachment (SNPA) and the asso- 
ciated SNPA address. 

1L5.3.3 A SNPA is a point of attachment between a 
real subnetwork and another piece of equipment, which 
may be a real end system, an interworking unit or an- 
other real subnetwork. Points of attachment to a real 
subnetwork may be identified within the context of the 
real subnetwork by an address assigned by the 
administrative authority of the real subnetwork. This 
address, both in the real world and in abstract usage, is 
referred to as the Subnetwork Point of Attachment Ad- 
dress, the SNPA-address or simply subnetwork address. 



NOTES 

1 To give an example, where the real subnetwork is a pubHc 
data network, an SNPA is called a DTE/EXTE interface, and its 
SNPA-address is called a EHE-address. 

2 In the case of two real subnetworks attached at an SNPA, 
different SNPA-addresses may be assigned by the authorities of 
the two real subnetworks to that SNPA. 

11.5.3.4 An SNPA is not a service-access-ooint, and 
an SNPA-address is not a network-address. Con- 
figurations of physical equipment determine the rela- 
tionships between NSAPs and SNPAs in the Network 
Layer. Since a real end system may be attached, pos- 
sibly multiply, to more than one real subnetwork, the 
relationships between NSAPs and SNPAs may be many- 
to-many and complex. 

11.5.3.5 The determination of the NPAI for different 
Network Layer protocols is an important Network Layer 
addressing operation. In many circumstances, multiple 
protocols are needed to support one instance of 
communication in the Network Layer. The type of ad- 
dressing information that each such protocol conveys, 
and how it is used, are determined by the role of the pro- 
tocol in the complete protocol structure. 



11.5.4 Network 
functions 



Layer use of directory 



11.5.4.1 At the Network Layer, the network-directory- 
funciions directly derive the network-address from the 
network-PAl. 

11.5.4.2 In the initiating system, on receipt of a net- 
work-service request primitive, the network-entity: 

a) uses IRFl and IAF2 to derive the called-daia- 
link-address (which is passed in a data-link-service 
request primitive) from the called-network-address 
and local information; 

b) uses IRFl and iAF3 to derive the calling-data- 
link-address (which is passed in a data-link-service 
request primitive) and the local DLSAP through 
which the data-link-service primitive is issued from 
the calling-network-address, the called-network-ad- 
dress, the called-data-link-address, and local infor- 
mation; 

c) uses IRFl and IPFl to derive the called-net- 
work-PAI and the called-subnetwork-address 
information from the called-network-address and lo- 
cal information; 

d) uses IRFl and IPF2 to derive the calling-net- 
work-PAI and the calling-subnetwork-PAI from the 
called-network-address. the calling-network-address 
and local information. ♦ 
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11.5.4.3 In the recipient system on receipt of a data-, 
link-service indication primitive, the network-entity: 

a) uses RAFl to derive the called-network-address 
from the called-network-PAI, and from local 
information; 

NOTE - Lxx^ information may be used to resolve a called- 
network-address (that refers to a set of NS APs) to a single 
NSAP. 

b) uses RAF2 to derive the calling-network-address 
from the calling-network-PAI; 

c) uses RAF3 to derive the responding-data-Unk- 
address from the called-data-link-address and from lo- 
cal information. 

($ uses RPFl to derive the responding-network- 
PAI from the responding -network-address which is 
received in a network-service response primitive. 

11.5.4.4 In the initiating system, for connection- 
mode operation, on receipt of a data-link-service confir- 
mation primitive, the network-entity derives the 
responding-network-address directly from the responding- 
network-PAL 

11.5.4.5 Routing is required within the Network 
Layer when communication between a pair of sets of 
NSAP's is relayed by a chain of network-entities. Rout- 
ing functions use the network-address of a called set of 
NSAPs to select a sequence of relay entities forming a 
path to the called-network-address. 



11.6 Data Link Layer 
11.6.1 Introduction 

11.6.1.1 A data-link-address identifies a set of Data- 
Link-Service- Access-Points (DLSAPs). The network 
entities bound to these DLSAPs are thus located by 
means of that data-link-address. Such a binding has to be 
known to the initiating open system. It may be recorded 
in the Network Address Directory Facility. 

NOTE - For some data-link protocols, data-link-addresses are 
implicit, that is the semantics of the data-link-addresses are not 
physically carried in the DLPCI. The use of these implicit data- 
liiik- addresses is consistent with the characterization of nil 
selectors in 9.5.2, 

11.6.1.2 A data-link-entity may be bound to more 
than one DLSAP and more than one Physical-SAP 
(PhSAP), thus creating a many-to-many correspondence 
between DLSAPs and PhS APs. 

NOTE - This correspondence may be constrained to simpler 
configurations through data-link -protocol specification. 

11.6.1.3 Data-link-addresses need only be unique 
within the scope of the set of open systems attached to a 



common Data-Link Layer, and within this scope the 
data-link-address must be equally valid regardless of 
which physical-address is used. 

11.6.2 Data-Link Layer use of directory- 

functions 

11.6.2.1 In the initiating system, on receipt of a data- 
link-service request primitive, the data-link-entity: 

a) uses IAF2 to derive a called-physical-address, 
(which is passed in a physical-service request 
primitive) from the called-data-link-address, and from 
local information; 

b) uses LAF3 to derive the calling-physical-address, 
(which is passed in a physical-service request primi- 
tive), and the local PhSAP (through which the 
physical-service primitive is issued), from the called- 
physical-address, the calling-data-hnk-address, and 
local information. 

NOTE - The choice of the PhSAP at which this primitive is 
issued is a local matter. This choice has to be consistent 
with the calling-physical-address. 

c) uses IPFl to derive the called-data-link-PAI 
from the called-data-link-address; 

d) uses IPF2 to derive the cailing-data-link-PAI 
from the calling-data-link-address; 

11.6.2.2 In the recipient system, on receipt of a 
physical-service indication primitive, the data-link-entity: 

a) uses RAFl to denvp the called-data-link-address 
from the called-dala-link^AI, the called-physical-ad- 
dress, and from local information; 

NOTE - Local information may be used to resolve the 
called-data-link-address (that refers to a set of DLSAPs) to a 
single DLSAP. 

b) uses RAF2 to derive the calling-data-iink-ad- 
dress from the calling-data-link-PAI and the calling- 
physical-address; and 

c) uses RPFl to derive the responding-dala-link- 
PAI from the responding-data-link-address which is 
received in a data-link-scrvice response primitive. 

11.6.2.3 In the initiating system, for connection- 
mode operation, on receipt of a physical-service confir- 
mation primitive, the data-link-entity derives the re- 
sponding-data-link-address from the responding-data-link- 
PAI and, possibly, the responding-physical -address. 



11.7 Physical Layer 

11.7.1 A physical-address idcntifk;s a set of PhSAPs. 
The data- link-entities bound to these PhSAPs are thus 
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lcx;ated by means of that physical-address. Such a bind- 
ing may be recorded in the Network Address Directory 
racnuy. 

11.7.2 Physical-addresses need only be unique within 
the scope of open systems attached to a common physi- 
cal medium communication path. Therefore, (N)-direc- 
tory-functions are not used at the Physical Layer. 

NOTE - Physical-addresses may be implicit. 



12 Naming domains and authorities 

12.1 A Naming Authority allocates names according to 
specified rules. A Naming Authority merely dispenses 
names but does not perform the binding of names to the 
objects they name. 

12.2 Naming-domains may be hierarchically de- 
composed into naming-subdomains. The naming-do- 
main at the top of the hierarchy is known as a global 
naming-domain. Each subset (subdomain) of a global 
naming-domain is put under the control of a naming-au- 
thority and does not intersect with other subsets allocated 
to different naming-authorities. 

12.3 The global naming-domain is the set of all 
possible names, within the OSIE, for objects of a spe- 
cific type. For example, the set of all application-en- 
tity-titles. Independent global naming-domains may ex- 
ist within the OSIE for objects of different types. 

12.4 The global naming-domain may be partitioned 
(hierarchically decomposed) into naming-subdomains. 
Thus, any naming-subdomain is also a naming-domain. 

12.5 Names taken from different subdomains of the 
global naming-domain may be bound to the same object. 
Thus, synonyms may arise. 

NOTE - The requirements for synonyms have been lecognized, in 
particular in tjfie naming of network-service-access-poinis 
(synonymous network-addresses), application-entities 
(synonymous application-entity-titles),and application-processes 
(synonymous application-process-tides). 

12.6 Each naming-domain is administered by a nam- 
ing-authority. A naming-authority is a registration au- 
thority, which only registers names and only has an ad- 
ministrative role. Although naming-authorities register 
the use of names, they do not participate in the binding 
of the name to an object. A naming-authority may re- 
gister names itself or it may partition the naming-do- 
main into naming-subdomains and delegate to a subdo- 
main naming-authority, the responsibility for naming 
within each naming-subdomain. The procedures for a 
naming-authority ensure the registration of unambiguous 
names and, if necessary, provide any rules that subdo- 



main naming-authorities must comply with to meet the 
registration requirements. 

NOTE - There are a number of ways by which the procedures for 
a naming-authority may ensure that names registered by a sub- 
authority are unamoiguous. Particular examples are: 

a) the allocation of a subset of names from the total set 
controlled by the naming-authority; 

b) the definition of a name component to be added to the 
name determined by the sub-authority. 

12.7 The establishment of naming-authorities requires 
agreement on the rules for specifying names within the 
naming-domain and for the creation of further su- 
bdomains. 

12.8 Within a hierarchy of naming-authorities the op- 
eration of each authority is independent of that of the 
other naming-authorities at the same level, subject only 
to any common rules established by the registration pro- 
cedures imposed by the parent authorities. 

12.9 A user of a naming-authority may request an al- 
location of names from a naming-authority, leaving the 
choice of names to the naming-authority. Alternatively, 
a user of a naming-authority may request an allocation of 
particular names. The naming-authority may grant that 
request if it chooses (provided the names have not 
previously been issued). The user of a naming-authority 
may interpret the names issued by a naming-authority in 
any way it chooses. The use of a name can be termi- 
nated and then the name re-iised at a later time. The pre- 
cise rules and constraints on the re-use of a name to en- 
sure that no ambiguity results are specified by the proce- 
dures for the naming-authority. 



13 Registration procedures for 
naming within OSI 

13.1 The operation of naming within OSI requires 
the establishment of registration procedures: 

a) for the assignment of titles which are unam- 
biguous throughout the OSIE for the following ob- 
jects: 

1) real open systems (system-tide), 

2) application-processes, 

3) application-process-types, 

4) applic^tion-entity-types; and 

b) for the assignment of network-addresses which 
are unambiguous throughout the OSIE. 
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13.2 Registered titles or addresses may or may not 
have synonyms: 

a) a single real open system has only one system- 
title; 

b) a single application-process may have more 
than one application-process-tide; 

c) a single NSAP may be identified by pore than 
one network-address. 



14 Directory facility requirements 

14.1 Introduction 

14«l.l Two Directory Facilities are required: 

a) the Application Title Directory Facility that 
processes either an application-process-litle or an 
application-entity-title and returns addressing infor- 
mation, as described in 14.2; and 

b) the Network Address Directory Facility that 
processes a network-address and provides the 
information used below the network-service bound- 
ary to access tiie remote NSAP, as described in 14.3. 

NOTE - In the case where a real open system provides 
both Directory Facilities, the retrieval of information from 
both Directory Facilities may be made in a single inquiry. 

14,1.2 Directory Facilities and the information held 
by them may be centralized or distributed, and non- 
replicated, partially replicated or fully replicated. Where 
communications are needed among Directory Facilities 
and systems which use these facilities, these 
communications utilize the normal OSI communication 
methods available to all application-processes. 

14. L3 Although, the user of a primitive name need 
not be aware of the structure of the name, e.g., the 
structure resulting from the registration authority, the 
Directory Facility may physically and logically organize 
Directory Facility information according to that st- 
ructure. 



application-entity-type-title. Descriptive names will be 
given in a standard descriptive language. 

14*2.2 The Application Title Directory Facility sup- 
ports both generic application-process-titles (e.g. 
application-process-type-titles) and non-generic ap- 
plication-ifl'ocess-titles. The Application Title Directory 
Facility supports both generic application-entity-titles 
(e.g. application-entity-type-titles) and non-generic ap~ 
plication-entity-tiiles. 

14.2.3 Using a generic application-process-title as 
input to the Application Title Directory Facility results 
in the return of a list of the associated application-pro- 
cess-titles. Any of these may then be subsequently used 
as input to the Application Title Directory Facility. 
Using a generic application-entity-title as input to the 
Application Title Directory Facility results in the return 
of a list of the associated application-entity-titles. Any 
of these may then be subsequently used as input to the 
Apphcation Title Directory Facility. 

14.2.4 Using a non-generic application-process-title 
as input to the Application Title Directory Facility, re- 
sults in the return of the list of application-entity-titlcs 
for the application-entities belonging to the application- 
process. 

14.2.5 Using a non-generic application-entity-title as 
input to the Application Title Directory Facility results 
in the associated addressing information in the form of 
the tuple: 

(P-selector, S -selector, T-selector, (list of Network Ad- 
dresses)) 

14.2.6 The Application Title Directory Facility is 
composed of two different components: 

a) a "name resolver" which can resolve an ap- 
plication-process-title/application-entity-title that is 
a descriptive name into the application-process-ti- 
Ue/application-cntity-title that is the primitive name 
of the application-proccss/application-entity; and 

b) a "directory" that returns the information 
associated with an application-process-ti- 
tle/application-entity-titlc that is a primitive name. 



14.2 The 
Facility 



Application Title Directory 



14.2.1 The input to the Application Title Directory 
Facility is an application-process-title or an application- 
entity-title. This may be a primitive name or a descrip- 
tive name. If it is a descriptive name, it is not neces- 
sarily complete, i.e., some attributes may be "don't 
cares". Possible attributes for a descriptive name are the 
system-title, the application-process-type-tiile, and the 



14,3 The Network Address Directory Facility 

The input to the Network Address Facility is a network- 
address which is a primitive name. Using a network -ad- 
dress as input to the Network Address Directory Facility 
results in the associated addressing information necessary 
at the Network Layer and the layers below. 
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